Measuring Latency in Iridium Satellite Constellation Data Services

The use of Satellite Communications (SATCOM) has become essential to operations in both Afghanistan and Iraq. In particular, the Iridium satellite constellation has demonstrated its usefulness and flexibility. It has had significant impact on how operations are conducted. Iridium provides users both voice and data services. There are two approaches to sending data over the Iridium network: a circuit-switched data service and message-switched data service. Use of the circuit-switched data service requires the overhead of a setup in the same manner as a voice call. There are two message-switched data services: Short Burst Data (SBD) and Short Message Service (SMS). Our testing involves the SBD message-switched data service, which is optimized for high capacity and efficiency when sending small amounts of data through the Iridium network. While there are many users for these services, little information can be found about their actual performance in fielded systems. The best sources of information are specifications or modeling of the performance of these services. We perceived that understanding the underlying network performance was needed, and we established experiments to capture that performance. We present results from both circuit-switched data service and message-switched SBD data service. We also address insights into the use of these services. 1 Relevance to Command and Control Effective command and control in regions without an established or accessible communication infrastructure relies on the communication paths provided by geosynchronous or satellite constellations. When a network application uses a satellite, there are expectations of latency. Network-centric application developers need to understand that underlying performance; and take into account operational characteristics of commercial services such as satellite call capacity and call setup times. With Low Earth Orbit (LEO) constellations such as Iridium, there are also considerations associated with look angles to satellites and revisit and coverage times of the constellation. Contrary to common understanding, Iridium service does not cover the whole globe at all times. An important part of Command and Control systems is the timely delivery and fusion of data from multiple sensors that often have overlapping areas of coverage. The Tactical Component Network (TCN®) technology transparently integrates sensor and communications suites with distributed network applications. TCN has a local component, called the TCN Local Network that handles time-critical, peer-to-peer applications, and a wide-area capability called the TCN Global Network. The global TCN uses a hub-and-spoke architecture to allow geographically dispersed systems to share data, and to interact with applications resident on the hub. The Iridium constellation is used as one type of spoke in the hub-and-spoke architecture of the global version of the TCN. Iridium was employed during US Navy 7 Fleet exercises, where TCN was used to integrate sensor data from multiple ships in a Beyond Line Of Site (BLOS) operational environment. At the end of each spoke into the hub was a Tactical Component Network (TCN) node, typically consisting of a local area network (LAN), multiple processors, cryptographic equipment and various peripherals. Some data provider nodes connected TCN to sensors such as the AN/SPS-48 radar on USS Essex, and others such as the USS Guardian provided mine information to other users. Currently, global TCN data is transmitted via circuit switched method via an encrypted Iridium data link. The message-based SBD service is being investigated as an alternative data transmission method for applications not requiring continuous connectivity. 2 Introduction This paper addresses the methods and experiments used to gain insight into the performance of spokes when they are implemented by the Iridium constellation. Our approach was to measure the actual latencies for these data services. In separate experiments, circuit-switched data calls and SBD message-switched data transmission latencies were quantified. For the circuit-switched experiments, a custom client-server application was built and instrumented. The SBD types of transmissions analyzed were: Mobile Originated (MO), Mobile Terminated (MT) and Full Duplex. 3 Related Work In [1], the authors describe an application of the Iridium network to support communication needs of passenger, flight and cabin crews for voice, data and paging. Voice latency was estimated to be between 270-390 milliseconds (ms). Effective channel throughput delay for data (1024 bit message) is estimated between 427 ms and 1.7 seconds. Simulation of Iridium satellite networks performed by [5] estimated an upper limit of the average end-to-end delay to be 210 ms when passing through twelve satellites. These studies were based on assumptions, rather than measurements. 4 Background The data transfer rate for Circuit-Switched Data (CSD) is 300 Bytes/sec and for SBD is 125 Bytes/sec. A CSD data requires that the satellite acquisition and call setup has been completed. However, an SBD transfer requires only that satellite acquisition has completed. This potentially makes SBD a better choice for Low Probability of Intercept (LPI) / Low Probability of Detection (LPD) applications [3]. Given that satellite acquisition has occurred, SBD is able to transfer 100 Bytes in approximately 1 second. Each SBD call can transfer a maximum of to 1960 Bytes from a mobile system to a gateway, and a maximum of 1,890 Bytes from gateway to a mobile system [3].